Fix the runtime of TestChildWatch and TestSetWatchers #88
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TestChildWatch was introduced to test what happens when the response is too large for the default allocated buffer size. It used to create 10k nodes which could take a very significant amount of time. The same effect can be achieved with far fewer nodes, significantly speeding up the test's runtime. The test now runs in 5s on my machine instead of sometimes multiple minutes... TestSetWatchers tested something similar, except that it checks that the outgoing setWatchers packet is broken up into multiple packets when it's too large. Using a similar trick we can generate names of specific lengths to test that the behavior is correct. It was also flaky because if your local ZK deployment is a little slow, deleting all the nodes can take longer than the session timeout, spuriously failing the test. This has also been fixed, and the test now runs in a little over 5 seconds as well, instead of failing. Finally, standardize the ZK server version checking to be a bit more flexible and friendlier towards future versions of ZooKeeper (note: the original implementation doesn't even work because the env variable name is incorrect... It `ZK_VERSION`, not `zk_version`)
jeffbean
added a commit
that referenced
this pull request
Apr 28, 2024
inspiration from #88 cleanup up the logic. but the idea is to support the tests requiring a version of ZK based on the API support in ZK.
jeffbean
added a commit
that referenced
this pull request
May 27, 2024
inspiration from #88 cleanup up the logic. but the idea is to support the tests requiring a version of ZK based on the API support in ZK.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TestChildWatch was introduced to test what happens when the response is too large for the default
allocated buffer size. It used to create 10k nodes which could take a very significant amount of
time. The same effect can be achieved with far fewer nodes, significantly speeding up the test's
runtime. The test now runs in 5s on my machine instead of sometimes multiple minutes...
TestSetWatchers tested something similar, except that it checks that the outgoing setWatchers packet
is broken up into multiple packets when it's too large. Using a similar trick we can generate
names of specific lengths to test that the behavior is correct. It was also flaky because if your
local ZK deployment is a little slow, deleting all the nodes can take longer than the session
timeout, spuriously failing the test. This has also been fixed, and the test now runs in a little
over 5 seconds as well, instead of failing.
Finally, standardize the ZK server version checking to be a bit more flexible and friendlier towards
future versions of ZooKeeper (note: the original implementation doesn't even work because the env
variable name is incorrect... It
ZK_VERSION, notzk_version)